Add a "cancel" event for when file upload selection is unchanged #6735

domenic · 2021-06-03T20:36:40Z

Closes #6376.

Specific choices made:

I chose "cancel" for the event name since we already have that (for <dialog>) and it seems nicer to reuse that than introduce something confusingly-similar (like "abort").
~~I left bubbles as false since most modern events don't seem to bubble. Maybe this is confusing though since both change and input bubble. I'm very open to changing this.~~ Flipped based on below feedback.
I left composed as false. Interestingly input is composed but change is not. input event is composed but change isn't #5453 I'm not sure what the right thing to do here is.

At least two implementers are interested (and none opposed):
- Gecko and Blink have both expressed interest in Specify cancelling a file upload from a file input #6376 and reviewed the specific proposal here.
Tests are written and can be reviewed and commented upon at:
- Probably not possible with web platform tests unfortunately. It still might be good to write manual tests? Or are those just kinda useless?
Implementation bugs are filed:
- Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1227424
- Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1719703
- Safari: https://bugs.webkit.org/show_bug.cgi?id=227799

(See WHATWG Working Mode: Changes for more details.)

/indices.html ( diff )
/input.html ( diff )

Closes #6376.

adroitwhiz

This fulfills the use case I had in mind in #6376!

With regards to event bubbling, I prefer API surfaces that are consistent rather than following the practices at the time each new feature is added, and I think that would be less confusing for web developers (though I'm not sure who would attach event handlers to a parent element rather than the input element itself). I'm a bit uneducated as to how event bubbling works, but are there any cancel events that could already be emitted by parent elements and listened for, that could cause compatibility issues if the input element starts emitting them as well and bubbling?

annevk

This looks good to me.

I would be okay with this being a composed event as I mentioned in that issue for its counterpart, but it's probably best to decide on them jointly.

cc @smaug----

source

domenic · 2021-06-23T20:29:46Z

@mfreed7 do you want to review this? Any thoughts especially on the "Specific choices made" section would be welcome.

mfreed7 · 2021-07-08T00:02:48Z

source


     <li><p>Wait for the user to have made their selection.</p></li>

-     <li><p><span>Update the file selection</span> for the <code>input</code> element.</p></li>
+     <li><p>If the user dismissed the prompt without changing their selection, then <span>queue an


Do we need to be more specific here? As written, this would fire "cancel" if a user selected a file, clicked OK, re-opened the file picker, selected the same file again, and clicked OK. In that case, the selection "would not be changed". Is that intentional? If so, perhaps this case could be explicitly folded into the new note below.

Yeah, I think that's right. Such a case would fire "cancel" and not "change", since nothing changed. I'll add it to the example.

Hmm, well, it kind of depends; something might have changed, since maybe the files changed on disk? But I don't think the event should need to branch on that.

So I guess now I'm thinking it's up to the UA. As long as it picks one of the two events it's OK. I'll try to come up with some phrasing...

Thinking about this a bit more, I'm thinking the more correct thing would be to fire change in this case (re-selecting the same file). The issue is that otherwise, a developer would have no way to detect this situation. There are two possibilities:

Re-selection triggers cancel: There is no way to disambiguate re-selection from hitting cancel.

Re-selection triggers change: The developer can, if they like, store the previously-selected file, and compare them upon receipt of change.

It seems plausible that a developer might want to do something different when the user clicks "ok" vs "cancel".

Yeah, I think that's up to the UA. It seems like a valid user interface to say that if the user didn't change anything (i.e. re-selected the same files), then that shouldn't be distinguishable from hitting cancel.

mfreed7 · 2021-07-08T00:10:05Z

Overall this looks pretty good to me. I added a question about re-selecting the same file. And here are my thoughts on the choices:

Specific choices made:

I chose "cancel" for the event name since we already have that (for <dialog>) and it seems nicer to reuse that than introduce something confusingly-similar (like "abort").

I think "cancel" makes sense, both because of parallelism with other APIs but also because it maps to the name of the button ("Cancel") used by most UAs.

I left bubbles as false since most modern events don't seem to bubble. Maybe this is confusing though since both change and input bubble. I'm very open to changing this.

I was surprised by this one, I would have thought we'd set bubbles=true here. But no strong opinions.

I left composed as false. Interestingly input is composed but change is not. input event is composed but change isn't #5453 I'm not sure what the right thing to do here is.

From our last spec triage meeting, I think the consensus was that composed=false is the right thing here. Cancelling a file dialog is not a "super global user action" like click and keydown.

domenic · 2021-07-08T16:33:08Z

I'll change it to bubble since we've gotten a couple of small pieces of feedback in that direction.

tomayac · 2021-07-19T14:45:17Z

Follow-up question: is there a way to feature-detect support for this? My initial approach…

  'oncancel' in (i = document.createElement('input'), i.type = 'file', i)
  // `true`

…was not helpful.

domenic · 2021-07-19T15:04:49Z

I don't believe so, no.

The event on `<input type=file>` was missing and implemented only in Firefox: whatwg/html#6735 https://bugs.chromium.org/p/chromium/issues/detail?id=1227424 https://bugzilla.mozilla.org/show_bug.cgi?id=1719703 https://bugs.webkit.org/show_bug.cgi?id=227799

The event on `<input type=file>` was missing and implemented only in Firefox: whatwg/html#6735 https://bugs.chromium.org/p/chromium/issues/detail?id=1227424 https://bugzilla.mozilla.org/show_bug.cgi?id=1719703 https://bugs.webkit.org/show_bug.cgi?id=227799 Co-authored-by: Queen Vinyl Da.i'gyu-Kazotetsu <[email protected]>

dbaron · 2022-11-23T14:57:49Z

I'm curious if it was intended that this change also applied to a drag/drop action that leaves the file selection unchanged. The current spec text for that says:

If the element is mutable, the user agent should allow the user to change the files on the list in other ways also, e.g., adding or removing files by drag-and-drop. When the user does so, the user agent must update the file selection for the element.

which seems to imply that cancel events should never fire for that case. This difference seems a little odd... and also seems to expose the mechanism the user used to change the selection, which may be undesirable.

domenic · 2022-12-05T05:03:03Z

Interesting question. When would you expect the cancel event to fire? After all, most of the time the user is not dragging-and-dropping files. It seems like it's the two-stage nature of (1) opening a picker, (2) then closing it, which lets us definitively decide at (1) that we're definitely going to fire an event, and at (2) which event to fire. Dropping is a single action, so I don't know how we would determine this...

dbaron · 2023-02-24T15:11:16Z

I guess if the user drops the same set of files as the current set, I'd expect either (a) a cancel event or (b) no events at all to fire at that time. Firing an input and a change event when the files didn't change exposes (I think) that the action was drag/drop rather than via the picker. (Also, for the file picker case, Chromium, at least, fires the input and the change events at the same time, after the user has closed the picker.)

(Also, for the picker case, I don't recall if there are currently APIs that allow the page to open the file picker, but if there are, that's a good reason that a cancel event should be exposed.)

dbaron · 2023-02-24T15:12:01Z

(Or, to more directly answer the question, I'd expect that cancel event to fire at the same time that the spec currently fires the input and change events.)

tomayac · 2023-02-24T15:19:50Z

Not sure if it's immediately relevant, but I just encountered an interesting corner case: pointing an <input type="file" webkitdirectory="" /> at an empty directory causes no change event. Should it cause a cancel event?

dbaron · 2023-02-24T15:20:47Z

I should also note that Chromium uses the same code to handle both receiving dropped files and a result from the file chooser. So fixing the latter to fire cancel events in some cases will also fix the former at the same time.

(Not sure about the webkitdirectory case... but the above CL might change that behavior.)

dbaron · 2023-02-24T15:34:17Z

Also, the older version of https://chromium-review.googlesource.com/c/chromium/src/+/4048886 has a test that might be worth adding to WPT if this discussion concludes.

annevk · 2023-02-24T15:34:22Z

@dbaron @tomayac could you please file new issues to track these concerns?

dbaron · 2023-02-24T15:36:11Z

Filed #8945.

See html spec [1] [2]. If the file upload selection for input type=file is unchanged, we should fire the cancel event with bubbles true. [1] https://html.spec.whatwg.org/#show-the-picker,-if-applicable [2] whatwg/html#6735 Change-Id: I8fb0307df75c58c17ff1d180071cd77634a08a65 Fixed: 1227424 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4048886 Commit-Queue: Di Zhang <[email protected]> Reviewed-by: David Baron <[email protected]> Cr-Commit-Position: refs/heads/main@{#1109778}

xiaoxiyao · 2023-03-23T04:01:12Z

How should I detect whether the browser supports this event？

Add a "cancel" event for when file upload selection is unchanged

3c37dfb

Closes #6376.

domenic added addition/proposal New features or enhancements topic: forms topic: events labels Jun 3, 2021

domenic mentioned this pull request Jun 3, 2021

Specify cancelling a file upload from a file input #6376

Closed

tranhieu0807 approved these changes Jun 4, 2021

View reviewed changes

adroitwhiz approved these changes Jun 4, 2021

View reviewed changes

annevk approved these changes Jun 17, 2021

View reviewed changes

source Show resolved Hide resolved

source Show resolved Hide resolved

Review comments

6989420

domenic added the agenda+ To be discussed at a triage meeting label Jun 17, 2021

mfreed7 reviewed Jul 8, 2021

View reviewed changes

Review feedback

5b15293

domenic merged commit 9c4374f into main Jul 8, 2021

domenic deleted the file-upload-cancel branch July 8, 2021 16:45

past mentioned this pull request Jul 20, 2021

Upcoming HTML standard issue triage meeting on 7/1/2021 #6739

Closed

dlech mentioned this pull request Mar 14, 2022

Promise never resolves when dialog is canceled TomokiMiyauci/file-select-dialog#5

Open

ditman mentioned this pull request May 7, 2022

[image_picker][web] cancel cause picker to never return flutter/flutter#92176

Closed

foolip mentioned this pull request Jul 4, 2022

Demix cancel event from GlobalEventHandlers mdn/browser-compat-data#16847

Merged

mfreed7 mentioned this pull request Jul 11, 2022

Apply/Cancel using showPicker() of type="color" #8090

Open

rr-codes mentioned this pull request Oct 4, 2022

Implement cancel event on <input type=file> WebKit/WebKit#4986

Merged

dbaron mentioned this pull request Feb 24, 2023

events fired when drag/drop of files leaves set of files unchanged differ from events fired when file chooser leaves set of files unchanged #8945

Open

tomayac mentioned this pull request Feb 24, 2023

<input type="file" webkitdirectory="" /> and empty directories #8946

Open

This was referenced Dec 12, 2023

"cancel" event for HTMLInputElement mdn/mdn#490

Closed

No information about "cancel" event on HTMLInputElement page mdn/content#31014

Closed

zam157 mentioned this pull request Feb 20, 2024

chooseImage 在H5中选择图片取消后应该触发fail dcloudio/uni-app#4731

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add a "cancel" event for when file upload selection is unchanged #6735

Add a "cancel" event for when file upload selection is unchanged #6735

domenic commented Jun 3, 2021 •

edited by pr-preview bot

Loading

adroitwhiz left a comment

annevk left a comment

domenic commented Jun 23, 2021

mfreed7 Jul 8, 2021

domenic Jul 8, 2021

domenic Jul 8, 2021

mfreed7 Jul 8, 2021

domenic Jul 8, 2021

mfreed7 commented Jul 8, 2021

domenic commented Jul 8, 2021

tomayac commented Jul 19, 2021

domenic commented Jul 19, 2021

dbaron commented Nov 23, 2022

domenic commented Dec 5, 2022

dbaron commented Feb 24, 2023

dbaron commented Feb 24, 2023

tomayac commented Feb 24, 2023

dbaron commented Feb 24, 2023

dbaron commented Feb 24, 2023

annevk commented Feb 24, 2023

dbaron commented Feb 24, 2023

xiaoxiyao commented Mar 23, 2023

Add a "cancel" event for when file upload selection is unchanged #6735

Add a "cancel" event for when file upload selection is unchanged #6735

Conversation

domenic commented Jun 3, 2021 • edited by pr-preview bot Loading

adroitwhiz left a comment

Choose a reason for hiding this comment

annevk left a comment

Choose a reason for hiding this comment

domenic commented Jun 23, 2021

mfreed7 Jul 8, 2021

Choose a reason for hiding this comment

domenic Jul 8, 2021

Choose a reason for hiding this comment

domenic Jul 8, 2021

Choose a reason for hiding this comment

mfreed7 Jul 8, 2021

Choose a reason for hiding this comment

domenic Jul 8, 2021

Choose a reason for hiding this comment

mfreed7 commented Jul 8, 2021

domenic commented Jul 8, 2021

tomayac commented Jul 19, 2021

domenic commented Jul 19, 2021

dbaron commented Nov 23, 2022

domenic commented Dec 5, 2022

dbaron commented Feb 24, 2023

dbaron commented Feb 24, 2023

tomayac commented Feb 24, 2023

dbaron commented Feb 24, 2023

dbaron commented Feb 24, 2023

annevk commented Feb 24, 2023

dbaron commented Feb 24, 2023

xiaoxiyao commented Mar 23, 2023

domenic commented Jun 3, 2021 •

edited by pr-preview bot

Loading